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REMARKS 

Applicants thank the Examiner for the telephone interview of May 27, 2009. The 
contents of the interview are summarized by the remarks below. 

Independent claims 1, 9, 17, and 25 are amended to further clarify the nature of 
the user context and the information included in a registered process. Support for these 
amendments can be found, for example, at pages 11 - 14 of the specification as filed and in the 
claims as filed. The claims are also amended to remove the phrase "according to selected 
criteria". No new matter is introduced. 

Independent claim 37 is canceled. New independent claim 44 is added. Support 
for new independent claim 44 can be found, for example, in the claims as originally filed and 
pages 1 1 - 14 of the specification as filed. Dependent claims 39, 40, 42, and 43 are amended for 
consistency with these changes. No new matter is introduced. 

Reconsideration of the above-identified application in view of the above 
amendments and the following remarks is respectfully requested. 

Rejections based on 35 U.S.C. § 103 

The following rejections are respectfully traversed: Claims 1, 2, 4, 6, 9-12, 14, 
15, 17, 18, 20, 22, 25-30, 32, 35, 39, 40 and 42 are rejected under 35 U.S.C. 103(a) as begin 
unpatentable over Beyda (U.S. Publication No. 2003/0229722, hereinafter Beyda) in view of 
Hinckley (U.S. Patent No. 5,828,882, hereinafter Hinckley). Claims 5, 21, 31, 33 and 43 are 
rejected under 35 U.S.C. 103(a) as being unpatentable over Beyda and Hinckley in view of 
Cahill (U.S. Patent No. 5,428,784, hereinafter Cahill). 

The claimed invention as amended 
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Claims 1, 9, 17, and 25 as amended provide further definition for the user context. 
This additional definition is also incorporated into new claim 44. The user context must include 
a user context state, which is a variable that indicates a state for a particular portion of a user 
context. One example of the state variables described by the present invention are the Boolean 
variables described, for example, at pages 11 - 14 of the specification as filed. A Boolean 
variable is an example of a state variable that has two states (True and False). The user context 
further defines a communication event that occurs for at least one value of the user context state. 
As described in the specification, the communication event is an event in response to receiving a 
notification for display. Numerous examples of communication events are provided in the 
specification. Additionally, a rule that provides a condition for modifying a defined 
communication event is also required. Examples of such rules are provided, for example, at page 
14 of the specification as filed. 

The Beyda reference 

Beyda describes a method for providing notifications, such as notifications about 
the availability of messages from an instant messaging service. Beyda describes the possibility 
of implementing rules to govern when a notification is provided to a user, as well as rules for 
when a message could be provided to the sender of an instant message regarding whether an 
instant message was delivered. Beyda further includes a description of having time dependent 
rules, where a user is given a certain amount of time to indicate that it is desirable to receive a 
message, the message being handled in a different manner if the user does not respond. 

Combination of user context and rules 

Beyda fails to describe or suggest several features of the claims as amended. 
First, Beyda does not describe or suggest having both rules and a user context that includes a 
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user context state. In the claimed invention, one or more user context states can be defined that 
determine whether a notification is delivered. For example, a "full screen" user context state can 
be defined as true or false, depending on the status of the window the user is currently operating 
in. As described in the specification, a user can define the user context so that when "full 
screen" is true, notifications are not delivered. Another example of a user state is "in a meeting." 
At least one state of the user context will define an alternative action for handling a notification. 
Rules can then be layered on top of a context to modify the alternative action. For example, if 
the context "in a meeting" is true, notifications are not delivered. However, a rule can then 
specify that notifications are delivered, if the notification relates to a person attending the 
"meeting". 

Beyda does not describe or suggest this interaction between context and rules. 
Beyda describes only a single layer, which is described as rules in Beyda. Regardless of whether 
the "rules" in Beyda are compared to the user context or the rules of the claimed invention, it is 
clear that the "rules" in Beyda cannot serve both functions, as Beyda does not describe or 
suggest the concept of having a user context that defines a communication event depending on a 
the user context state, and then having a rule that specifies a condition for modifying the 
communication event. The combination of Beyda with Hinckley and/or Cahill does not cure the 
above defects. 

Thus, independent claims 1, 9, 17, 25, and 44, and all corresponding dependent 

claims, are believed to be allowable for at least the above reason. 

Receiving information regarding the change of user context state 

With regard to at least claims 1 and 44, Beyda also fails to describe or suggest 

receiving an indication regarding the change of a user context state. In the claimed invention, a 



3455969v2 



Page 14 of 16 



Application No. 10/809,249 
Response Filed 06/15/2009 
Reply to Office Action of 04/15/2009 

registered process, such as a calendar program, contains information regarding at least one user 
context state. For example, if a user has a meeting scheduled in the calendar, the calendar can 
provide information about when the meeting begins and ends. Both events are potential times to 
change an "in a meeting" user context state. The calendar program can forward state change 
information to a notification program when a state change occurs, or the calendar program could 
wait until it is asked by a notification program. Either way, the calendar program (or other 
registered process) provides the information about the user context state change, and this 
information is received by another process as an indication of a change in the user context state. 

Beyda does not appear to have an equivalent to user context states, where a 
process informs another process about the state change. Instead, Beyda appears to build this type 
of information directly into rules, such as by having a rule providing for one type of behavior 
during normal business hours, and another type of behavior after normal business hours. For 
these rules, the user context is not being determined, so there is no information to be passed 
between processes. Instead, the action to take based on the rule is determined completely by 
what a clock or timer indicates. 

Part of the reason why Beyda fails to describe or suggest having a registered 
process provide information is due to the fact that Beyda fails to describe or suggest registration 
of a process. The Office Action notes Hinckley as describing the registration of processes. 
While Hinckley generally describes registration, the combination of Hinckley and Beyda still 
provides no description or suggestion of having a registered process provide information about 
the change of a user context state. More generally, the combination of Hinckley, Beyda, and/or 
Cayhill fail to overcome the deficiencies described above. Thus, claims 1, 9, and 44, and all 
corresponding dependent claims, are believed to be allowable for at least this additional reason. 
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CONCLUSION 

Having demonstrated that all rejections of the claims have been overcome, this 
application is in condition for allowance. Accordingly, Applicants request early and favorable 
reconsideration in the form of a Notice of Allowance. 

If there are any questions regarding this amendment or the application in general, a 
telephone call to the undersigned would be appreciated, since this should expedite the 
prosecution of the application for all concerned. Alternatively, the Examiner is expressly 
authorized to contact the undersigned by e-mail at lecarter@shb.com . 

No additional fees are believed to be necessary. However, if necessary to effect a 
timely response, this paper should be considered as a petition for an Extension of Time sufficient 
to effect a timely response. Please charge any deficiency in fees or credit any overpayments to 
Deposit Account No. 19-2112. 

Respectfully submitted, 

/LAWRENCE E CARTER/ 

Lawrence E. Carter 
Reg. No. 51,532 

LEC 

SHOOK, HARDY & BACON L.L.P. 

2555 Grand Blvd. 

Kansas City, MO 64108-2613 

816-474-6550 

Lawrence Carter Direct Dial: 949-975-1722 
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